|
In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD).〔(【引用サイトリンク】title=Behaviour-Driven Development )〕 Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.〔 Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.〔 Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD. BDD is largely facilitated through the use of a simple domain specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes. Test scripts have long been a popular application of DSLs with varying degrees of sophistication. ==History== Behavior-driven development is an extension of test-driven development:〔 development that leverages a simple, domain-specific scripting language. These DSLs convert structured natural language statements into executable tests. The result is a closer relationship to acceptance criteria for a given function and the tests used to validate that functionality. As such it is a natural extension of TDD testing in general. BDD focused on: * Where to start in the process * What to test and what not to test * How much to test in one go * What to call the tests * How to understand why a test fails At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues. For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. Acceptance tests should be written using the standard agile framework of a User story: "As a () I want () so that ()". Acceptance criteria should be written in terms of scenarios and implemented as classes: Given (context ), when (occurs ), then (some outcomes ) .〔 Starting from this point, many people developed BDD frameworks over a period of years, finally framing it as a communication and collaboration framework for developers, QA and non-technical or business participants in a software project.〔 (The RSpec Book – Question about Chapter 11: Writing software that matters )〕〔 During the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North〔Dan North: (How to sell BDD to the business )〕 gave the following description of BDD:
Dan North created a BDD framework, JBehave,〔 followed by a story-level BDD framework for Ruby called RBehave〔D.North, (Introducing RBehave )〕 which was later integrated into the RSpec project.〔S.Miller, (InfoQ: RSpec incorporates RBehave )〕 He also worked with David Chelimsky, Aslak Hellesøy and others to develop RSpec and also to write "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". The first story-based framework in RSpec was later replaced by Cucumber mainly developed by Aslak Hellesøy. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Behavior-driven development」の詳細全文を読む スポンサード リンク
|